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REMARKS 

This comnmmcation is responsive to the Office Action mailed 2 May 2006. In this 
paper, the Applicant has amended claims 1, 3, 9, 24 and 27. The Applicant submits that 
these amendments are completely supported by the application as originally filed and 
contain no new matter. 

Claims 1-28 are currently pending. 

Allowable Subject Matter - Claims 3-6. 20-23. 27snd28 

The Office Action indicates that claims 20-23 are allowed. 

The Office Action indicates further that claims 3-6, 27 and 28 would be allowable if 
rewritten in ind^endent form to incorporate the features of their respective base claims and 
any intervening claims. The Applicant has done this by amending claim 3 to incorporate 
the features of claim 1 and by amending claims 27 to incorporate the feature of claim 24. 
Based on these amendments, claims 3 and 27 are in condition for allowance. Claims 4-6 
depend from claim 3 and claim 28 depends from claim 27 and are submitted to be allowable 
for at least this reason. 

Claims 1 and 2 

The Office Acdon raises US patent No. 6,775,284 (Calvignac &t al.) and US patent 
publication No, 2004/0208122 (McDysan) in connection with claims 1 and 2, The 
Applicant submits that claims 1 and 2 patentably distinguish the combination of Calvignac 
et al. and McDysan. 

As understood by the Applicant, Calvignac el al. disclose a method for protocol and 
frame classification in a data processing system which includes analyzing a portion of the 
packet or frame according to predetermined tests , then storing key characteristics of the 
packet for use in subsequent processing of the frame. The stored key characteristics of the 
packet are then used by the network processing system in its further processing of the 
frame. The processor is preconditioned wilii a starting instruction address and the location 
of the beginning of the layer 3 header as well as flags for the type of frame. That is> the 
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instraction address or code entry point is used by the processor to start processing for a 
frame at the right place, based on the type of frame. 

The portion of Calvignac et al, which describes protocol and frame classification 
includes Figures 4 and 5 and the accompanying description at coL 10, In. 44-col. 12, In. 
39. As shown in Figure 4, Calvignac et al. disclose a hardware classifier 118 which assists 
a packet processor 110. Hardware classifier 118 examines up to the first 384 bits of an 
incoming frame and determines a locajdon 122a-122f within instruction memory 122 of 
processing instructions to be executed on the particular frame being processed. Hardware 
classifier 118 looks at various bytes of the frame to determine: (i) if the "Ethernet type" of 
the frame matches a known protocol (block 210); (ii) whether the SAP field of the frame 
matches a known protocol (block 220); (iii) whether the frame contains a SNAP field 
representing a different type of encapsulation (block 240); and (iv) whedicr VLAN usage is 
present in the frame (block 250). This process (disclosed in Figure 5 and the 
accompanying description at col. 11, In. 55 to col. 12, In. 39) involves looking at particular 
bvtes of the frame and comparing these bvtes to expected values for particular known 
protocols and encapsulation methods. 

The output of blocks 210, 220, 240 and 250 is provided to classification controller 
260. Classification controller 260 looks up the infomxation obtained from blocks 210, 220, 
240 and 250 in a look-up table (unlabelled in Figure 4, but referred to in the description as 
"table 280"). Each entry in table 280 corresponds to a particular combination of the 
information determined in blocks 210, 220, 240, 250. The entries in table 280 represent 
pointers 122a-122f to locations in instruction memory 122. The table 280 pointers 
122a-122f specify locations in instruction memory 122 of instructions to be carried out on 
the particular frame being processed. Hardware classifier 118 provides one of the pointers 
122a- 122f to packet processor 110 as signal 176. Packet processor 110 then fetches the 
appropriate instructions from instruction memory 122 and processes the frame accordingly. 

Claim 1 recites "a) obtaining first information regarding a packet; b) using the first 
information as an index into a parser memory: c) retrieving from the parser memory an 
entry comprising a location in the packet of one or more protocol bits specifying a protocol 
associated with the packet. " The Applicant submits that Calvignac et al. do not disclose 
this combination of claim 1 features. The Examiner expresses the view that the ETYPE 
compare block 250, the SAP compare block 220 and the table 280 disclosed by Calvignac 
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et al "together are a parser memory" (see pages 2 and 3 of the Office Action). However, as 
shown in Figure 4, the only inputs to this alleged parser memory are FISHl, nSH2 and 
FISH3, nSHl , FISH2 and FISH3 are pans of the frame itself and are not used " as an 
index into a parser memory " as recited in claim 1. 

In contreist to claim 1, Calvignac et al. describe a series of guess^ as to the location 
of protocol bits within the incoming frame (see Figure 5 and col. 11, In. 55 to col. 12, In. 
39). This series of guesses involves looking at particular bytes of the frame and comparing 
these bytes to expected values for particular known protocols and encapsulation methods 
(see compare blocks 320, 322, 324, 340, 350, 360 and 370). This process does not amount 
to "using the first information as an index into parser memory " as recited in claim 1. 
Calvignac et al. do not teach or suggest any component which could be properly interpreted 
as an index to the alleged parser memory. 

Claim 1 also recites "d) obtaining a match engine index; and, e) rnmhTTiin y th^ 
protocol bits and the match engine index to g^enerate a kev for retrieving a match engine 
entry from a match engine memory, the match engine entry con:Q)rising an action to take on 
the packet. " The Examiner correctly states (on page 3 of the Office Action) that Calvignac 
et al. '*does not specifically disclose that both the protocol bits an [sic] the match engine 
index are used as a key to the memory". However, the Examiner contends (on pages 6 and 
7 of the Office Action) that this deficiency of Calvignac et al. is overcome by McDysan. 

According to the Examiner, McDysan discloses "using a protocol type as well as 
other packet header information, to index a table containing instructions regarding the 
processing of a packet" at paragraph [Q046\ . McDysan refers to a classifier table 82 which 
may have a immber of indices including Source Address (SA) and Destination Address 
(DA), Source Port (SP), Destination Port (DP), Protocol Type (PT), DSCP or other field 
from the packet's headers. Table 82 is shown in Figure 4. As explained in paragraph 
[0047] and shown in Figure 4, each of the indices of table 82. including the protocol tvne 
(yp. is used independently to index ta*le 82 (i.e. each of the indices represents a separate 
column of table 82), Locating instructions in table 82 requires each of the indices to be 
considered separatelv . McDysan does not disclose combining the protocol type (PT> with 
anv other information to obtain a single key to a match engine memory. More particularly, 
McDysan fails to teach or suggest the claim 1 feature of " combining the protocol bits and 
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the match engine index to generate a key for retrieving a match engine entry fixim a match 
engine memory." 

Based on this reasoning, the Applicant submits that claim 1 patentably distinguishes 
the combination of Calvignac et ai. and McDysan. Claim 2 depends from claim 1 and is 
submitted to patentably distinguish the combination of Calvignac et al. and McDysan for at 
least this reason. 

Claim 7 

The Office Action raises Calvignac et al-, McDysan and US patent No, 6,289,414 
(Feldmeier et al.) in connection with claim 7. 

Claim 7 depends from daim 1. The Applicant submits that Feldmeier et al, fail to 
remedy the above-discussed deficiencies of Calvignac et al. and McDysan. Accordingly, 
the Applicant submits that claim 7 patentably distinguishes the combination of Calvignac et 
al., McDysan and Feldmeier et al. 

The Office Action raises Calvignac et al,, McDysan and US patent publication No, 
2002/0163935 (Paatela et al.) in connection with claim 8. 

Claim 8 depends from claim 1. The Applicant submits that Paatela et al. fail to 
r^edy the above-discussed deficiencies of Calvignac et al. and McDysan. Accordingly, 
the Applicant submits that claim 8 patentably distinguishes the combination of Calvignac et 
al,, McDysan and Paatela et al. 

Qaim9 

The Office Action raises the combination of Calvignac et al. and McDysan in 
connection with claim 9. The Applicant submits that claim 9 patentably distinguishes the 
combination of Calvignac et al. and McDysan. 

Claim 9 recites "a step for obtaining first information regarding a packet; a step for 
usin^ the first information as an index to retrieve an entry from a parser memory : and a 
step for retrieving from the packet one or more protocol bits identified by the parser 
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memory entry. " Again the Examiner contends that the Calvignac et al. ETYPE compare 
block 250, SAP con:q)are block 220 and table 280 "together are a parser memory". 
However, as discussed above in relation to claim 1, Calvignac et al. do not teach or suggest 
any component which could be properly interpreted as " an index to retrieve an entry from a 
parser memory" as recited in claim 9. In contrast, Calvignac et al. describe a series of 
guesses as to the location of protocol bits within an incoming frame (see compare blocks 
320, 322, 324, 340, 350, 360 and 370 of Figure 5 and col, 11, In. 55 to col. 12, In. 39). 
This process does not amount to "a step for usin^r the first information as an index to 
retrieve an entry from a parser memory " as recited in claim 9, 

The Exanuner correctly states (on page 4 of the Office Action) that Calvignac et al. 
"does not specifically disclose that both the protocol bits an [sic] the match engine index are 
used as a key to the memory " . The Examiner contends (on pages 6 and 7 of the Office 
Action) that McDysan shows this feature missing from Calvignac et al. However, claim 9 
recites "a step for retrieving from a match engine memory a match engine memory entry 
comprising an action to perform using a match engine key comprising a cmnhinflt ion of the 
protocol b its and a match engine index . " As discussed above in relation to claim 1, 
McDysan shows a look up table 82 that can be indexed by a plurality of independent 
indices, one of whirfi inchxdes the protocol type (PT). However, McDysan fails to disclose 
cnmhininp the prot ocol tvpe flPT) with anv other indices or any other ififormat jon to obtain 
a single key for retrieving a match engine entry from a match engine memory. More 
particularly, McDysan fails to teach or suggest the claim 9 feature of "a step for retrieving 
from a match engine memory a match engine memory entry comprising an action to 
perform using a match engine key co mprising a combination of the protocol bits and a 

Tnafeh ftnp;inft inHpy " 

Based on this reasoning, the Applicant respectfully submits that claim 9 patentably 
distinguishes the combination of Calivignac et al. and McDysan. 

CMinsIOsndJJ 

The Office Action raises Calvignac et al. , McDysan and Paatela et al. in connection 
with claims 10 and 11. 

Claims 10 and 11 depend from claim 9, The Applicant submits that Paatela et al, 
fail to remedy the above-discussed deficiencies of Calvignac et al. and McDysan. 
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Accordingly, the Applicant submits that claixns 10 and 1 1 patentably distinguish the 
combination of Calvignac et al., McDysan and Paatela et al. 



Claims 12 

The Office Action raises Calvignac et al. and McDysan m connection with claim 12. 
The Applicant submits that claim 12 patentably distinguishes the combination of Calvignac 
et al- and McDysan. 

Claim 12 recites "a control logic circuit; a parser memory accessible to the control 
logic circuit the parser memory comprising a phiralitv of entries each specifying a location 
in a packet of one or more protocol bits and at least some of which specifying a match 
e]]igine index; a match engine memory accessible to the control logic circuit, the match 
engine memory comprising a plurality of entries each specijfying an action to be taken; and, 
a context memory accessible to the control logic circuit, the context memory comprising a 
phiralitv of entries each specifying a match engine index," 

Again die Examiner expresses the view that the Calvignac et al. ETYPE compare 
block 250, SAP compare block 220 and table 280 "together are a parser memory" . The 
Examiner contends that ETYPE compare block 250 and SAP block 220 have entries 
specifying the location of protocol bits within a packet. This contention is erroneous. 
ETYPE compare block 250 and SAP block 220 operate by making a series of guesses as to 
the location of protocol bits within a frame (see compare blocks 320, 322, 324, 340, 350, 
360 and 370 of Figure 5 and col. 1 1, hi. 55 to coL 12, In. 39). ETYPE compare block 250 
and SAP block 220 do not comprise " a plurality of entries each specifying a location in a 
packet of one or more protocol bits " as recited in claim 12. 

The Examiner also expresses the view that instruction memory 1 12 disclosed by 
Calvignac et al. has the features of the match engine memory recited in claim 12. 
However, in addition to a parser memory and a match engine memory, claim 12 recites "a 
context memory accessible to the control logic circuit, the context memory comprising a 
plurality of entries each specifying a match engine index ." The Examiner has not alluded 
to any disclosure of Calvignac et al. which shows such a context memory. The Applicant 
submits that Calvignac et al. foil to disclose or suggest a context memory having the 
features recited in claim 12. 
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The Examiner correcdy notes (on page 5 of the Office Action) that Calvignac et al. 
"does not specifically disclose that both the protocol bits an [sic] the match engine index are 
used as a key to the memory" . The Examiner contends (on pages 6 and 7 of the Office 
Action) that McDysan shows this feature missing from Calvignac et al. However, claim 12 
recites "the control logic circuit is configured to generate a match engine key by cnTnhi'ning 
protocol bits of a packet identified in a parser memorv entry with a match engine index 
from an entry of either the parser memory or the context memory^ to retrieve from the 
match engine memory an entry corresponding to die match engine key. " As discussed 
above in relation to claim 1, McDysan shows a look up table 82 that can be indexed by a 
plurality of independent indices, one of which includes the protocol type (PT). However, 
McDysan fails to disclose combining the protocol tvoe rPT) with any other indices or anv 
other infnrmatjpn t o obtain a single key for retrieving a match engine entry from a match 
engine memory- More particularly, McDysan fails to teach or suggest the claim 12 feature 
of "the control logic circuit is configured to generate a match engine key by nnmhim'ng 
protocol bits of a p acket identified in a parser memorv entry with a match engine index 
from an entry of either the parser memory or the context memory, to retrieve from the 
match engine memory an entry corresponding to the match engine key," 

Based on this reasoning, the Applicant respectfully submits that claim 12 patentably 
distinguishes the combinatian of Calivignac et al, and McDysan, 

Claims XS-^ 9 

The Examiner raises Calvignac et al., McDysan and Paatela et al. in connection 
with claims 13-19. 

Claims 13-19 depend from claim 12. The Applicant submits that Paatela et al. fail 
to remedy the above-discussed deficiencies of Calvignac et al. and McDysan. Accordingly, 
the Applicant submits that claims 13-19 patentably distinguish the combination of Calvignac 
et al., McDysan and Paatela et al. 

ClAim24 

The Office Action raises Calvignac et al. and McDysan in connection with claim 24. 
The Applicant submits that claim 24 patentably distinguishes the combination of Calvignac 
et al. and McDysan. 
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Claim 24 recites ''means for retrieving first information about a received packet; 
means for using the first information as an index to a parser memory to retrieve, from the 
parser memory, a parser memory entry corresponding to the first information, the parser 
memory entry comprising a location in the packet of one or more protocol bits specifying a 
protocol associated with the packet and a match engine index. " Again the Examiner 
contends that the Calvignac et al. ETYPE compare block 250, SAP compare block 220 and 
table 280 "together are a parser memoiy". However, as discussed above in relation to 
claim 1, Calvignac et al. do not teach or suggest " using the first iTifonnation as an index to 
a parser memory " as recited in claim 24. In contrast, Calvignac et al. describe a series of 
guesses as to the location of protocol bits within an incoming frame (see compare blocks 
320, 322. 324, 340, 350, 360 and 370 of Figure 5 and col. 11, hi. 55 to coL 12, In. 39). 
This process does not amount to " using the first information as an index to a parser 
memory to retrieve, firom the parser memory, a parser memory entry corresponding to the 
first information" as recited in claim 24. 

The Examiner correctly notes (on page 6 of the Office Action) that Calvignac et al. 
"does not specifically disclose that both the protocol bits an [sic] the match engine index are 
used as a key to the memory" . The Examiner contends (on pages 6 and 7 of the Office 
Action) that McDysan shows this feature missing from Calvignac et al. However, claim 24 
recites "means for combining the protocol bits with the w ^^trh ftnfr jne index to generate a 
match engine kev: means for retrieving an action corresponding to one of a plurality of 
match engine entries which matches the match engine key, " As discussed above in relation 
to claim 1, McDysan shows a look up table 82 that can be indexed by a plurality of 
independent indices, one of which includes the protocol type (PT). However, McDysan 
fails to disclose combining the protocol type fPT) with any other indices or anv other 
information to obtain a single kev for retrieving a match engine entry fi-om a match engine 
memory. More particularly, McDysan fails to teach or suggest the claim 24 feature of 
"means for comhininp the protocol bits with the match engine index to generate a match 
engine kev : means for retrieving an action corresponding to one of a plurality of match 
engine entries which naatches the match engine key . " 

Based on this reasoning, the Applicant respectftiUy submits that claim 24 patentably 
distinguishes the combination of Calivignac et al. and McDysan. 
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niaimx 25 And 26 

The Examiner raises Calvignac et al-, McDysan and Paatela et al, in connection 
with claims 25 and 26. 

Claims 25 and 26 depend from claim 24. The Applicant submits that Paatela et al. 
fell to remedy the above-discussed deficiencies of Calvignac et al. and McDysan. 
Accordingly, the Applicant submits that claims 25 and 26 patentably distinguish the 
combination of Calvignac et al., McDysan and Paatela et al. 



Conclusion 

The Applicant submits that the foregoing amendments place this application in condition for 
allowance. The Applicant respectfully requests reconsideration and allowance of this 
application. 



By: 



Vancouver, B.C. 
CANADA 




Bla 

Registratioi^No, 29,505 
tel: 604.669.3432 ext. 8936 
fex: 604,681.4081 
e-mail: bwiggs@patentable.com 
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